home *** CD-ROM | disk | FTP | other *** search
/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / AMIGA / AMICUS / AMICUS12.ADF / Text / Cardco.TXT < prev    next >
Text File  |  1986-08-05  |  10KB  |  265 lines
  1. File: AMIGA.4037
  2. From: jimm@amiga.UUCP (James D. Mackraz)
  3. Newsgroups: net.micro.amiga
  4. Subject: Re: Fraud And Deceit In The Memory Board Market
  5. Date: 10 Jul 86 18:30:03 GMT
  6. Reply-To: jimm@homer.UUCP (Jim Mackraz)
  7. Organization: Commodore-Amiga Inc., 983 University Ave #D, Los Gatos CA 95030
  8. Lines: 21
  9. Keywords:
  10.  
  11. Let me first say that I haven't had the opportunity to verify the following,
  12. but you can test for yourself. 
  13.  
  14. We have had reports that the drhystone benchmark runs significantly slower in
  15. extended memory than in a 512K machine, if that extended memory is CardCo. 
  16. Those with CardCo mem, can you check? It would be interesting to measure
  17. differences in copying large files from RAM:a to RAM:b for a 512K machine vs. 
  18. CardCo extended. 
  19.  
  20. One guy here claims to have hooked up a scope and observed a "goodly number"
  21. of wait states in the CardCo card.  Can anyone verify?
  22.  
  23. Flame this spot -> X if your observations are contrary to this second-hand
  24. information. 
  25.  
  26.             go wild.
  27.                 jimm
  28.  
  29.     "I have my two megabytes, what's your problem?"
  30.  
  31. File: AMIGA.4044
  32. From: rokicki@Navajo.ARPA (Tomas Rokicki)
  33. Newsgroups: net.micro.amiga
  34. Subject: Re: Fraud And Deceit (I'm mad as hell)
  35. Date: 12 Jul 86 23:30:17 GMT
  36. Organization: Stanford University
  37. Lines: 27
  38.  
  39.  
  40. I've got one of those CardCo boards, and yes, it does slow the machine
  41. down something awful.  Here are the stats:
  42.  
  43.    512K machine, 1.1      988 dhrystones
  44.    1536K machine, 1.1      674 dhrystones
  45.       Loss          31.8%
  46.    512K machine, 1.2 beta II   983 dhrystones
  47.    1536K machine, 1.2 beta II   664 dhrystones
  48.       Loss          32.5%
  49.  
  50. Which means I just paid so many hundreds of dollars to SLOW DOWN MY MACHINE!
  51. Now, I've designed memory boards before; it's not that difficult to make the
  52. RAM run with no wait states on a 7.2 MHz machine.  To slow it down so much
  53. seems to indicate that two wait states are being introduced for EVERY MEMORY
  54. REFERENCE! This is inexcusable. 
  55.  
  56. (So is my use of capitals above, but I'm pissed.  I've been working very hard
  57. squeezing every ounce of performance out of my programs, and something like
  58. this comes out and destroys it all.)
  59.  
  60. File: AMIGA.4056
  61. From: rico@oscvax.UUCP (Rico Mariani)
  62. Newsgroups: net.micro.amiga
  63. Subject: Re: Fraud And Deceit (I'm mad as hell)
  64. Date: 13 Jul 86 19:32:36 GMT
  65. Organization: Ontario Science Centre, Toronto
  66. Lines: 61
  67. Keywords: Comspec, Dhrystone,  Memory
  68. Summary: 'Fast' ram is only 1% slower
  69.  
  70.  
  71. FYI, I ran the same tests on my Amiga with a Comspec memory board and the
  72. results were much more encouraging.  I only ran the tests once each (OK so
  73. I'm lazy...  gimme a break) so there is some variance compared to the above
  74. figures on an unexpanded Amiga.  I used 50000 cycles with no registers on
  75. Manx Aztec C with 16 bit integers.  The times were collected with my little
  76. brother's watch in stopwatch mode.  The numbers below have lots of digits
  77. after the decimal but I wouldn't really trust them too much.  I've also
  78. included the actual time that I measured for 50000 cycles. 
  79.  
  80.  
  81.     512K machine, 1.1          975.04 dhrys/sec = 51.28 secs for 50000 cycles
  82.     2.5M machine, 1.1          967.49 dhrys/sec = 51.68 secs for 50000 cycles
  83.     Comparison:  99.23% of top speed = 0.77% Loss
  84.  
  85.     512K machine, 1.2 Beta II  976.56 dhrys/sec = 51.20 secs for 50000 cycles
  86.     2.5M machine, 1.2 Beta II  963.58 dhrys/sec = 51.89 secs for 50000 cycles
  87.     Comparison:  98.67% of top speed = 1.33% Loss
  88.  
  89. As you can see, the times are close enough to each other that the stopwatch
  90. method really isn't accurate enough to get a  good figure for the difference.
  91. This should be good enough for the purpose of this experiment though.
  92.  
  93. Another FYI, the Comspec board uses 500mA in typical (not idle) operation.
  94. Remember that's a 2 meg board...  I can't tell you too much about the
  95. ground plane and such but it passes the "I can't see thru the PC board"
  96. test.  Then again, maybe the light I was using wasn't bright enough :-)
  97.  
  98.  
  99. DISCLAIMER: a) The Science Centre doesn't have anything to do with any of
  100.           this.  Leave them alone!
  101.  
  102.        b) I've enjoyed a healthy relationship with Comspec for a long
  103.           time now so my views may or may not be biased because of this.
  104.  
  105.        c) I don't know what I'm talking about at the best of times :-)
  106.  
  107.  
  108.    That's all
  109.      -Rico
  110.  
  111.       ...{allegra|ihnp4|decvax|watmath|linus}!utzoo!oscvax!rico
  112.  
  113. File: AMIGA.4082
  114. From: rokicki@navajo.STANFORD.EDU (Tomas Rokicki)
  115. Newsgroups: net.micro.amiga
  116. Subject: Re: Deceit
  117. Date: 16 Jul 86 20:55:57 GMT
  118. Organization: Stanford University
  119. Lines: 53
  120. Keywords: apology
  121.  
  122. Well, I just received a nice letter in response to my earlier flame,
  123. so, after receiving Richard Rodgers' permission, I quote:
  124.  
  125. --------------------------------------------------------
  126.  
  127. As president of the company that designed the C Ltd. (CardCo) board I offer
  128. my humblest apology.  It would seem that a last second PAL change did in
  129. fact make it into the final product without adequate testing.  The problem
  130. is currently being fixed, and the boards that did get out will be updated.
  131.  
  132. Not to justify, but to explain how this happened.  None of our (10+) beta
  133. testers found this problem.  The excessive wait states do not occur 100%
  134. of the time.  Our logic analyzer hard copy was "lucky" enough to catch
  135. a one wait state picture.  We then shipped 150 or so boards before the 
  136. problem was caught.  You got one of our 150 boards, and reported the problem
  137. a day after we had found it.  You probably called C Ltd., and were frustrated
  138. by the lack of answers you received. Sorry...
  139.  
  140. If you will send me your name, address, and/or phone number, I will
  141. personally see that you get an updated PAL as soon as it becomes available. 
  142. I would also like to stress that the board will probably still run with one
  143. wait state.  The reason for this wait state is that we had to "glue" an Intel
  144. chip onto a Motorolla bus.  The Intel chip was chosen because it was the only
  145. CMOS DRAM controller we could find.  A CMOS chip was necessary to accomadate
  146. the internal power specifications.  A one wait state memory board will NOT be
  147. a problem for 98%+ of our customers, so was approved. 
  148.  
  149. Richard N. Rodgers, President Creative Microsystems Inc.  9140 SW Locust
  150. Street Tigard, OR 97223
  151. --------------------------------------------------------
  152.  
  153. Made me feel better, anyway, that something was being done about it.  I
  154. have also learned that their expansion cage and it's memory card does not
  155. require any wait states.  I've been getting around the problem somewhat
  156. by forcing my programs into chip memory with a linker option.
  157.  
  158. True, one wait state is still perhaps too much, but I'm sure I'll survive
  159. until I can afford an expansion cage.
  160.  
  161. -tom
  162.  
  163. File: AMIGA.4121
  164. From: richr@pogo.UUCP (Rich Rodgers)
  165. Newsgroups: net.micro.amiga
  166. Subject: Re: Deceit
  167. Date: 18 Jul 86 15:54:08 GMT
  168. Organization: Creative Microsystems Inc.
  169. Lines: 71
  170. Keywords: apology
  171.  
  172.  
  173. CMI also felt that one wait state was too many, but did not want to say
  174. the board would run with no wait states until we were *positive* that it 
  175. could be done.  Since talking with Tom, we have found the problem with the 
  176. C Ltd. board.  It turned out not to be a PAL change as we originally
  177. suspected, but a strap to the DRAM controller that was incorrectly laid out.
  178.  
  179. I apologize to anyone that has been frustrated by this problem, but realize
  180. that we were even more upset than you.  The C Ltd. manufacturing line has
  181. been down for two-three weeks while we were solving this problem.  When you
  182. are backlogged in excess of one-thousand units, it is difficult to shut
  183. down the manufacturing line.  I am convinced that our problems have now been
  184. solved and that the C Ltd. aMEGA board is of the highest quality.
  185.  
  186. As a side note,to anybody that wants to make the change quickly, and is handy
  187. with a soldering iron. There is a row of straps at the top center of the
  188. board next to a large cap.  It is currently in the following state.
  189.  
  190.  
  191.             O O O O O O O O O
  192.             | | | |     |   |
  193.             O O O O O O O O O
  194.                     | |   |
  195.             O O O O O O O O O
  196.             -----------------
  197.             1 2 3 4 5 6 7 8 9
  198.  
  199. Take a small drill bit or exacto knife and cut strap 5.  Then solder a wire
  200. so that strap 5 is tied high.  Your straps will now look like this:
  201.  
  202.  
  203.             O O O O O O O O O
  204.             | | | | |   |   |
  205.             O O O O O O O O O
  206.                       |   |
  207.             O O O O O O O O O
  208.             -----------------
  209.             1 2 3 4 5 6 7 8 9
  210.  
  211. In the above configuration, the aMEGA board will run at NO, ZERO, NONE wait
  212. states.  (Mandelbrots in 640 * 400 will be *Much* faster than Chip RAM).
  213. Since only 150 boards were shipped, I do not know how many people on the net
  214. are affected.  If you are leary of using a soldering iron, and can be without
  215. your board for a few days, send me email and I will let you know how to get
  216. it updated.  (Even if I have to do the update myself).
  217.  
  218. Richard N. Rodgers, President
  219. Creative Microsystems Inc.
  220. 9140 SW Locust Street
  221. Tigard, OR  97223
  222.  
  223. tektronix!pogo!richr
  224. -- 
  225.             Rich Rodgers
  226.  
  227.             tektronix!pogo!richr
  228.  
  229. File: AMIGA.4137
  230. From: rokicki@navajo.STANFORD.EDU (Tomas Rokicki)
  231. Newsgroups: net.micro.amiga
  232. Subject: Re: Memory board timings
  233. Date: 21 Jul 86 00:50:34 GMT
  234. Distribution: net
  235. Organization: Stanford University
  236. Lines: 43
  237. Summary: NEW CardCo Timings
  238.  
  239.  
  240. I just fixed my CardCo board (my soldering iron is still hot), and these are
  241. the new updated timings:
  242.  
  243. 512K machine, 1.1            988 dhrystones
  244. 1.5M machine, 1.1            938 dhrystones
  245.    94.9% of top speed = 5.1% loss
  246.  
  247. 512K machine, 1.2 Beta II    983 dhrystones
  248. 1.5M machine, 1.2 Beta II    933 dhrystones
  249.    94.9% of top speed = 5.1% loss
  250.  
  251. So, it's taking about 5% away; sounds like refresh delays.  I suspect that
  252. this 5% will come back with interest on normal applications which access
  253. the disk and therefore use the coprocessors, though.  I also decided to run
  254. the Mandlebrot set and see what improvement I noticed there.  Here are the
  255. timings for mse (from the Fish disks) on a 640x200x4 screen, when the reset
  256. both window and region menu option is selected, for one scan of the window:
  257.  
  258. 512K machine, 1.1    56m 4s
  259. 1.5M machine, 1.1    31m13s
  260.    Speedup:  1.796 (79.6%)
  261.  
  262. Not bad!
  263.  
  264. -tom
  265.